Incident Response／Runbook／Status Page／Postmortem
建 Sev 級別、On‑call 值班表、Slack Warroom、狀態頁與無責任歸因事後檢討

職場對話開場（02:13 AM）

小可（被 LINE 鬧鐘吵醒）：「後台 5xx 飆到 32％！貝老闆人呢？」

貝老闆（語音哀號）：「我……在夢裡辦發表會！不是設定了 AI 自動護國神盾嗎？」

AI 實習生（單眼發亮）：「晚安~我不是護國神盾，我是您的 AI 實習生……目前偵測到大量 'Login 5xx Surge'。」

工程師 King（睡到長髮炸開）：「誰在 call 我？我今天不是 secondary 嗎？」

小可：「重點是——沒有 On‑call 表！大家都以為別人會接。Slack 沒 Warroom、狀態頁沒更新，客服被客戶追著跑。」

貝老闆（慌）：「那……先問 AI 看看？」

小可（甩摺扇）：「AI 不會幫你當指揮官啦！快打給好威。」

好威（電話另一端，駭客貓 T‑shirt）：「你們真的越來越過分！連這個都找我，先照流程來：
1）建立事件聊天室 #inc-20250825-0213，指派 Incident Commander（IC）＝小可；
2）分派 Ops Lead（King）、Comms Lead（貝老闆），AI 實習生當 Scribe；
3）把事件分級：Sev1（登入失效且佔比 > 20％，付費流程受影響）。

接著開 Runbook：《Login 5xx Surge》。先 Feature Flag OFF 促銷模組 → 驗證健康檢查 → 若 10 分鐘無改善就 Rollback 前一版。外部 Status Page 兩行文：『我們正在處理登入異常，預計 30 分鐘內更新進度。』」

貝老闆：「哇，這麼多角色分工喔？」

好威：「對，火場要有人當指揮。記住：No blame，先復原、後找根因。」

概念拆解

1）Sev 分級＋ On‑call 值班

「Sev」是 Severity（嚴重度） 的縮寫，用來為事件/故障分級，方便決定誰要被叫起來、回應時限、與對外通報節奏。訂 Sev 門檻時，通常看：影響範圍（多少使用者）、持續時間、是否有替代方案、法遵/財務風險，並對應 SLA/SLO、MTTA/MTTR 的處置目標。沒有分級就像消防車出門前不知道火勢大小。先定門檻：例如全站 5xx > 20％、付款失敗率 > 5％且持續 10 分鐘為 Sev1；區域或子功能異常為 Sev2。搭配 On‑call 輪班表（Primary／Secondary／Manager Escalation），明確 MTTA／MTTR 目標。

常見分級（範例）：
• Sev0/Critical：全站或關鍵金流大當機，立即全員支援、最高層級通報。
• Sev1/High：主要功能大範圍失效（如登入失敗率飆高），需 On-call 立即處理並對外更新。
• Sev2/Medium：部分功能壞、可繞路或影響較小，用工作時段修復。
• Sev3/Low：小瑕疵、文案錯字、非功能性問題，排進一般待辦。

新手問 AI 的方式：把歷史監控數據與商業指標貼給 AI，請它「產出 Sev 分級表＋告警規則草案，並用中文解釋為什麼」。值班前請 AI 生成交接清單：「今晚哪些風險最高？遇到 A、B、C 異常先做哪三步？」

2）Warroom 指揮鏈＋ Runbook

臨時群聊容易吵成菜市場，故建立 Slack Warroom 與固定角色：
• IC 指揮節奏
• Ops Lead 動手
• Comms Lead 對外說明
• Scribe 記錄時間線。
Runbook 以「情境」命名（例如《DB 連線池爆滿》、《Cache 失效》），列出偵測→緊急處置→回復→驗證。與變更管理連動：每次上線要有 Feature Flag／Rollback／DB Migrate + Downgrade 路徑。AI 的任務：自動把 Cloud 日誌、APM 圖貼進 Warroom，對照 Runbook 推薦下一步，並生出「已做／未做」差異清單；給非技術者的問法：「請用我聽得懂的話，告訴我現在要按哪個開關，風險是什麼」。

3）Status Page 通報＋ Postmortem 無責任歸因

客戶最怕沒消息。對外狀態頁用「現況、影響、下一次更新時間」三句話，遵守 10／30／60 分鐘節奏更新；內部客服話術一致。事後 Postmortem 不抓戰犯，聚焦時間線、技術根因、組織成因與「防再犯措施（Owner＋Due Date）」；度量 DORA 指標 與 MTTR 變化。讓 AI 幫忙初稿：丟入 Warroom 紀錄、PR、監控截圖，要求「以無責任語氣撰寫 Postmortem，附三個可驗證的改善項目」。

Takeaways

A. 先有制度再談神器

沒有 Sev 表、值班表、Runbook，再多監控也是吵鬧通知。讓 AI 先幫你「把散落的 SOP 彙整成一本 Runbook 目錄」，每週補齊一篇，三週就成形。新手可直接問：「請列出我們最常見的前五種事故情境與第一輪排查步驟。」

B. 指揮、溝通、紀錄分開，效率就上來
IC 不下手修機器，專心拉節奏；Comms Lead 負責對外說人話；Scribe 用時間線把決策記清楚。AI 很適合當 Scribe 與 Copilot：自動摘錄重點、產生下一步清單，還能在 30 分鐘到點提醒更新狀態頁。

C. 變更要有退路，資料要可降級
每次上線都準備 Rollback 與 DB Downgrade。請 AI 幫你檢查 PR：「若需回滾，哪些檔案與設定也要同步撤回？」把這題問清楚，比半夜手抖快太多。

D. 無責任歸因不是不負責
不罵人也要負起改善責任：每個改善項目都要有 Owner／Due Date／驗收標準。AI 可以在兩週後自動追蹤：「以下改善項目即將到期，是否需要協調資源？」

精煉重點

事件處理像打仗：角色要定、節奏要穩、資訊要一致。 先救火，再找根因。

AI 是好副手，不是消防隊。 請它寫 SOP、當紀錄員、幫通報，但指揮官永遠要是人。

迷你範本

Slack 啟動訊息

/incident start "Login 5xx Surge" sev:1 IC:@小可 Ops:@King Comms:@貝老闆 Scribe:@AI 實習生
下一次對外更新：30 分鐘後 02:45
第一步：關閉促銷 Feature Flag → 驗證健康檢查 → 準備 Rollback

Status Page 文案

我們偵測到登入異常，部分使用者無法成功登入。工程團隊已啟動緊急處置，下一次更新將於 30 分鐘後發布。造成不便，敬請見諒。

Postmortem 章節

• 摘要
• 時間線
• 影響範圍
• 技術根因
• 組織成因
• 修復動作
• 防再犯（Owner＋Due Date）
• 學到什麼

今日提問

• 你們公司目前有 On‑call 值班表 與 Sev 分級表 嗎？若沒有，最先要補哪一塊？

Prompt 小作業

「以下是我們過去三個月的監控指標與客服工單摘錄。請幫我依影響範圍與持續時間設計 Sev1～Sev3 的分級表、告警門檻與對應的首輪排查步驟，產生一頁 Runbook 草案。」